The invention relates to a secure packet processor.
Referring to FIG. 1, a server 12 may communicate with a client 10 by transmitting frames, or packets 8, of information over a network 18 pursuant to a network protocol. As an example, the network protocol may be a Transmission Control Protocol/Internet Protocol (TCP/IP), and as a result, the client 10 and server 12 may implement protocol stacks, such as TCP/IP stacks 17 and 19, respectively. For the client 10 (as an example), the TCP/IP stack 17 conceptually divides the client""s software and hardware protocol functions into five hierarchical layers 16 (listed in hierarchical order): an application layer 16a (the highest layer), a transport layer 16b, a network layer 16c, a data link layer 16d and a physical layer 16e (the lowest layer).
More particularly, the physical layer 16e typically includes hardware (a network controller, for example) that establishes physical communication with the network 18 by generating and receiving signals (on a network wire 9) that indicate the bits that make up the packets 8. The physical layer 16e recognizes bits and does not recognize packets, as the data link layer 16d performs this function. In this manner, the data link layer 16d typically is both a software and hardware layer that may, for transmission purposes, cause the client 10 to package the data to be transmitted into the packets 8. For purposes of receiving packets 8, the data link layer 16d may, as another example, cause the client 10 to determine the integrity of the incoming packets 8 by determining if the incoming packets 8 generally conform to predefined formats and if the data of the packets comply with cyclic redundancy check (CRC) codes or other error correction codes of the packets. The data link layer 16d may also perform address filtering.
The network layer 16c typically is a software layer that is responsible for routing the packets 8 over the network 18. In this manner, the network layer 16c typically causes the client 10 to assign and decode Internet Protocol (IP) addresses that identify entities that are coupled to the network 18, such as the client 10 and the server 12. The transport layer 16b typically is a software layer that is responsible for such things as reliable data transfer between two endpoints and may use sequencing, error control and general flow control of the packets 8 to achieve it. The transport layer 16b may cause the client 10 to implement a specific protocol, such as the TCP protocol or a User Datagram Protocol (UDP), as examples. The application layer 16a typically includes network applications that, upon execution, cause the client 10 to generate and receive the data of the packets 8. Quite often, the packets may be secure packets (Internet Protocol Security (IPSec) packets, as examples) that have security features that may delay processing of the packets by network devices, such as the client 10 and the server 12. The IPSec standard is discussed in Request for Comment (RFC) 2401, entitled xe2x80x9cSecurity Architecture for the Internet Protocol,xe2x80x9d dated November 1998. Requests for comments (RFCs) are available at several sites on the Internet.
As an example of the processing that is associated with secure packets, FIG. 2 depicts the conversion of an unsecure packet 30 into a secure packet 37. In particular, the client 10, for example, may use a two stage process to add security features to the packet 30. In this manner, the client 10 may first encrypt an unencrypted portion (called plaintext 32) of the packet 30 to produce an intermediate packet 36 that includes ciphertext 34, the encrypted version of the plaintext 32. Next, the client 10 may process the intermediate packet 36 to produce the secure packet 37 that includes an authentication signature 39 and the ciphertext 34. Secure packets that the client 10 receives from the network 18 may also be processed in a similar manner that first includes authenticating the received packet and then decrypting the ciphertext of the received packet. Unfortunately, the above-described processing contributes to the latency times that are introduced by converting between secure and unsecure packets.
Thus, there is a continuing need to address one or more of the problems stated above.
In one embodiment of the invention, a method usable with a computer system includes receiving a packet that includes encrypted data and indicates an authentication signature. The encrypted data is decrypted to produce second data, and the encrypted data is used to validate the signature concurrently with the decryption of at least a portion of the encrypted data.
In another embodiment, a method usable with a computer system includes receiving a packet that includes first data. The first data is encrypted to produce encrypted data. The encrypted data is used to form an authentication signature concurrently with the encryption of at least a portion of the first data.